docs: Roll out DR-002-Proc FEP process across contributor docs#3076
Conversation
github-project-automation
Bot
added this to
S-CORE Roadmap and TLC - Technical Lead Circle
|
The created documentation from the pull request is available at: docu-html |
|
|
||
| A proposal classified as **Breaking Change** must additionally include: | ||
|
|
||
| * **Impact Inventory**: explicit list of known integrators, configurations, or customer deliverables that will break |
There was a problem hiding this comment.
How is that related to this template now? https://eclipse-score.github.io/process_description/main/folder_templates/platform/features/feature_name/index.html
There was a problem hiding this comment.
You are right that the Breaking Change section doesnt clearly relate to FR template today, but I think the actual problem might be one level up.
The FR template currently serves two different purposes in one file: proposing a change (Motivation, Backwards Compatibility, Rejected Ideas, Open Issues - point-in-time, argument-for-the-change content) and documenting the resulting feature (Abstract, Rationale, Specification, Security/Safety Impact - living, current-state content).
My intent here (not yet fully reflected/settled): separate these explicitly. A Feature Change / FEP record carries the proposal-only content, including Backwards Compatibility, and lives with the change. Feature Documentation stays in docs/features/ with only Abstract, Rationale, Specification, Security Impact, Safety Impact, kept current as the feature evolves. Some headings would appear in both but ask a different question - e.g. Safety Impact of the feature overall vs. Safety Impact of this specific change - so one wouldnt simply reference the other.
This might be bigger than this PR since it touches FT template, used by every existing feature doc. Genuinely open on this - I would like your/the Process Communities read before committing.
There was a problem hiding this comment.
Added to the agenda of next Community Meeting
https://github.com/orgs/eclipse-score/discussions/2234#discussioncomment-17557191
There was a problem hiding this comment.
@masc2023 is this resolved or do you still see actions open to be incorporated to resolve the comment?
e8953f9 to
1c044ce
Compare
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
I have a hard time to understand this, need to re-review at a later time
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
now I re-reviewed all
1c044ce to
46c1f5a
Compare
| Feature requests are at the heart of our evolution. They describe the intended functionality of the S-CORE platform and serve as a collaborative starting point where maintainers and contributors align on new ideas. These requests not only define the motivation and requirements but also shape the technical roadmap for future developments. We invite you to check out all current feature requests on our | ||
| `Feature Request Board <https://github.com/orgs/eclipse-score/projects/4>`_. | ||
|
|
||
| New Feature and major Feature Modification requests go through the :need:`FEP process <doc__feature_request_guideline>`, where an Architecture Community Shepherd guides the proposal to a Final Comment Period before it's decided. Component-level and single-Feature-Team changes are handled directly by the responsible team, as described in the :need:`doc__platform_change_management_plan`. |
There was a problem hiding this comment.
As FEP process is part of Change Management Process, I would propose to call it FEP workflow, procedure, way or working, rather then process, compare PEP, intend is to describe new features/etc. for S-CORE or simply.
In the PMP you call it now Track...
...go through a Feature Enhancement Proposal (FEP), where an .....
|
|
||
| Feature Request Guideline | ||
| ############################## | ||
| Feature & Enhancement Proposal (FEP) Process |
There was a problem hiding this comment.
remove process, see also other comments
| Some changes carry enough governance weight that the decision is worth persisting, and the | ||
| community needs a structured way to reach agreement before implementation starts, rather than | ||
| relying on a single Committer's review. For these, **Analyze** is specialized into the **FEP | ||
| process**: a Shepherd sponsors the proposal, a time-boxed Final Comment Period |
There was a problem hiding this comment.
remove process in every place
| They are in the responsibility of the :ref:`Architecture Community <pmp_pm_arc>`, shall aligned with :ref:`Project / Technical Lead Circle <pmp_pm_plctlc>` and the issues are part of the :ref:`Root Repository <pmp_pm_root_repository>`. | ||
| other work packages, including as a parent to child Task issues used for implementation tracking once a FEP is accepted. *Feature Request* covers new Features as well as significant modifications of existing Features. | ||
|
|
||
| Feature Requests are governed by the FEP process (see the :ref:`FEP Process Guide <feature_request_guideline>`): the :ref:`Architecture Community <pmp_pm_arc>` owns the review via a Shepherd and Final Comment Period. The :ref:`Project / Technical Lead Circle <pmp_pm_plctlc>` triages incoming requests and is notified once a FEP enters its Final Comment Period, for roadmap awareness. Feature Requests are part of the :ref:`Root Repository <pmp_pm_root_repository>`. |
| **responsible for maintaining and evolving the architecture**. | ||
|
|
||
| By creating a **feature request**, structural changes as well as new functionality can be **proposed at any time**. | ||
| Structural changes and new functionality are proposed through the **FEP process**. |
There was a problem hiding this comment.
remove process everywhere
Implement the consequences of DR-002-Proc (FEP process) across the four affected documents: - feature_request.rst: rewritten as the living FEP Process Guide, superseding the old TL-circle review guideline. Defines roles (Author, Shepherd, Architecture Community), labels, the five process phases with tracking-issue lifecycle, and the FEP template. - change_management.rst: adds FEP routing for Feature and major Feature Modification CRs. - software_architecture_overview.rst: updates references from the old guideline to the FEP Process Guide. - project_management.rst: aligns the Feature Request definition with the FEP tracking issue (type Feature Request, allowed as a parent to child Task issues for implementation tracking). Assisted-by: Claude:claude-sonnet-5
46c1f5a to
953bab3
Compare
masc2023
left a comment
masc2023
left a comment
There was a problem hiding this comment.
my comments are resolved now
|
@aschemmel-tech can you check again? |
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
my comments resolved
4 participants
Implements the consequences of DR-002-Proc (accepted), which introducesthe Feature & Enhancement Proposal (FEP) process for Feature and major Feature Modification change requests.
Changes:
feature_request.rstrewritten as the living FEP Process Guide, superseding the old TL-circle review guideline: roles, labels, the five process phases with tracking-issue lifecycle, and the FEP template.change_management.rst: FEP routing added for Feature and major Feature Modification CRs.software_architecture_overview.rst: references updated to the FEP Process Guide.project_management.rst: Feature Request definition aligned with the FEP tracking issue (type Feature Request, may parent child Task issues for implementation tracking).See DR-002-Proc for the decision and rationale.
Refs #3061